1. Field of the Invention
The present invention relates to a process for allowing Applets to be resized independently from the WEB/HTML page they were created.
2. Description of the Prior Art
Java™ programs can be designed for deployment in one of two known run-time configurations: Application or Applet.
Application is the traditional way to deploy software, with an explicit installation phase where all necessary program files and configuration files are copied, with a well-defined tree organization, on the mass storage of the target run-time system, and then several execution phases where control is transferred to the entry point of the application which begins operating as designed.
This deployment scheme has the following pros and cons:                Since program files are permanently stored on the target machine, application startup is immediate.        To start the application, a specific, explicit command must be issued by the user.        When the application starts, it is usually independent from other applications, i.e. its lifetime is not necessarily correlated to other applications' lifetime.        Space is permanently occupied on each target machine's mass storage for holding program files and configuration files.        When a new version of the program is released, in order to update the program on the target machine, another installation procedure must be done, either integral or differential/incremental [upgrade].        
Applet deployment, on the other hand, has a different goal, and as a consequence of this, it differs from the previous scenario in many respects:                Applet code does not reside permanently on mass storage of the target run time system. It is stored on the mass storage of a centralized server, from which it is downloaded every time the Applet is started. This greatly simplifies administration of the target machines. If a new version of the software is released, it is not necessary to reinstall it on all target machines: it is sufficient to reinstall it on the centralized server and all target machines will download the new version at the first occasion. In situations where the same application must run on hundreds of target machines, this is a tremendous advantage over traditional installation scheme.        The Applet appears to the user as “embedded” in a WEB/HTML page, and it is transparently downloaded (from the centralized server) and activated (when download is complete) during a web browsing session without explicit commands.        Download prior to activation takes time, therefore, execution start cannot be immediate.        One or more Applets run “in” a web browser process (though possibly in several windows). When the web browser exits, all Applets also terminate, and their program files and configuration files, which were previously downloaded by the web browser, are “forgot” (unless caching is used to achieve long-term persistency of already downloaded program files).        
One possible way to fulfill a frequent technical requirement coming from users, like customers of a telecommunication network management system, i.e. to make GUI (Graphic User Interface) applications accessible via web, without any prior installation on the client machine other than operating system and web browser, is to develop them as Java Applets. This is especially useful when applications are accessed and activated remotely.
Unfortunately, when GUI applications are running as Java Applets, their size is determined by the WEB/HTML page where the Applet is embedded and cannot be modified by the user like it is normally possible for any other window. Only the web browser window can be resized, but the Applet area within the WEB/HTML page cannot grow. Furthermore, Applets are hosted in a different window (i.e. the browser's one), with its own menus and toolbars, and no possibility to alter or enrich their populations with Applet-provided menus. This renders the development of GUI applications not optimized in time and computer resourses.
More in details, software deployed in Applet mode appears to the final user like “embedded” in the web page contents. Although this visual effect may be desirable from a general point of view, there is an important drawback.
The size reserved to an Applet in a web page is fixed and pre-determined. For example, if we have a “word processor” Applet embedded in a web page, it could have been decided to reserve in the web page an area of W pixels wide and H pixels tall for its graphical interface.
Since the web page may be accessed from a number of clients, and these clients might have different screen sizes/resolution, the web page must be designed to make sure that it is possible to use the word processor Applet effectively on all clients, in particular, even on clients with the smallest screen.
For this reason, quite low values are usually selected for W and H (for example, 600×400 pixels), resulting in Applet sizes which are compatible with all target machine situations, but hardly optimal for target machines equipped with large, high-resolution screens (say, 1600×1200 pixels). On these machines, the word processor Applet will appear as a tiny area less than one fourth of the total available screen size, even if the user has no other application running at the moment.
With traditional applications, in this situation, the user would use window controls to maximize the window size, in order to use all available screen space to work more effectively.
With Applets, this is not possible, because Applet size cannot be changed. The size is “hardwired” in the WEB/HTML code of the web page which is “hosting” the Applet.
The above remarks explain the “Applet size” problem. Other problems exist, however; for example, “Applet multiwindowing”. This is the possibility to manage Applets just like ordinary applications, i.e. to have one independent window for each running instance of the software, which can be iconified, moved, sent to the background or brought to the foreground, . . . Applets do not have this flexibility, as they are embedded in web pages, and the best that can be done is to manage them through the web browser window which is displaying the web page which is hosting them. However this is not natural for the final user, it wastes screen space (the window usually carries as an overhead with it all menus of the web browser and the web page area around the Applet).
Therefore, while preserving the advantages connected to Applet-based software deployment and execution, there is the need to have a system to make it possible to resize Applets and to make them top-level windows.
Since Applets cannot change their size, but the surrounding WEB/HTML page can, usual known workarounds for the “Applet resize problem” include:                making Applet size as big as possible in the web page; or        use hybrid techniques to take advantage of the fact that the HTML is portion of the page can be resized; therefore, design the GUI so that only part of it is “active”, with fixed size, and implemented in Java, and everything else is in HTML, possibly with JavaScript; or        configure the Applet as zero-size and open a secondary window.        
However any a-priori choice about the Applet size cannot be adequate for all circumstances (there are constraints about the display size to take into account, too). Exploiting a mix of Java, HTML and JavaScript is not applicable to complex GUIs, makes application development harder and exposes the overall application behavior and appearance to variance in web browser features. The third solution is only partly acceptable because the connection between the Applet window and the web page is not evident, and the Applet can only run in the secondary window, even in case the user prefers to run it as a traditional Applet.
Other possible known solutions could be:                Design several web pages, for example one for small screens, one for medium screens, one for large screens, and reserve different Applet sizes in each situation; then ask the user to select the most appropriate web page for his/her screen resolution, or try to make this selection process assisted or semi-automatic. In any case, this does not solve the “Applet multiwindowing” problem.        Design the Applet so that although it is still actually embedded in the web page, from a lifetime point of view, its GUI is managed as an external (thus resizable, etc . . . ) window. This solves both problems, but the “Applet embedded in the web page” concept, which is appropriate and desirable in many situations, is lost.        